-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[browser] js string marshaling by value #95180
[browser] js string marshaling by value #95180
Conversation
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsMake string marshaling by value rather than by reference to The motivation is that
|
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand why we're doing this, but the code looks fine
c66f1b0
to
4a2bf17
Compare
|
# Conflicts: # src/libraries/System.Runtime.InteropServices.JavaScript/src/System.Runtime.InteropServices.JavaScript.csproj
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
@@ -115,6 +116,8 @@ | |||
<WasmEnableExceptionHandling Condition="'$(WasmEnableExceptionHandling)' == ''">true</WasmEnableExceptionHandling> | |||
<WasmEnableSIMD Condition="'$(WasmEnableSIMD)' == ''">$(WasmEnableExceptionHandling)</WasmEnableSIMD> | |||
<WasmEnableLegacyJsInterop Condition="'$(WasmEnableLegacyJsInterop)' == ''">true</WasmEnableLegacyJsInterop> | |||
<WasmEnableJsInteropByValue Condition="'$(WasmEnableJsInteropByValue)' == '' and ( '$(WasmEnableThreads)' == 'true' or '$(MonoWasmBuildVariant)' == 'multithread' )">true</WasmEnableJsInteropByValue> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't WasmEnableThreads
user facing, and MonoWasmBuildVariant
is meant more for the wasm/runtime build itself? I see that it is being used in a couple of other places, which we should fix too. Not necessary for this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes it easy to work in-tree with samples and unit tests when you just have MonoWasmBuildVariant
set globally and sometimes native rebuild kicks in. Maybe it could be unified somehow, I'm not 100% sure about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can set WasmEnableThreads
based on MonoWasmBuildVariant
in WasmApp.InTree.targets
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer if you could help me to improve it in different PR. But I would like to ask details in meantime
what are you supposed to use WasmEnableThreads
or MonoWasmBuildVariant
inside of
- wasm.proj
- WasmApp.Native.targets
- C code like drive.c triggered by
- runtime build (wasm.proj)
- external application native rebuild (WasmApp.Native.targets)
- in-tree sample native rebuild (WasmApp.InTree.targets)
- inside .csproj of libraries.
- inside .csproj of libraries unit tests
- inside .csproj of in-tree samples
- in .csproj of WBT
What are you supposed to use WasmEnableThreads
or MonoWasmBuildVariant
on commandline ?
- when you build runtime and libraries with
build.sh
- when you run unit tests. This could trigger re-build of C# libraries
- when you run samples in-tree. This could trigger re-build of C# libraries
How does it propagate to the nested build/publish ?
Does build on helix changes anything about it ?
Does WBT runtime installation in artifacts changes anything about it ?
Is there really benefit of having 2 of them ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MonoWasmBuildVariant
is really only for non-user projects, so wasm.proj would be an example.
All the other test cases (except WBT) use InTree targets, so adding overrides there would apply to all of them.
WBT strictly uses what the user gets, so no InTree targets.
Is there really benefit of having 2 of them ?
Not really. I think we had that before for multithread
, and perftrace
builds but now we don't need a string property. It is clearer to have them separate but I wouldn't mind using only WasmEnableThreads
either.
What I do want to avoid is using internal build properties in user facing targets.
cc @lambdageek
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
New MSbuild flag
WasmJsInteropByValue
which isfalse
by default on ST build andtrue
on MT build.Make string marshaling by value rather than by reference to
MonoString*
The motivation is that
This removes optimization we have for interned strings, when enabled.
I didn't fix it for legacy interop.